With communication becoming ubiquitous, more and more devices will become ‘connected’ and start to communicate. This is often referred to as machine to machine, M2M, communication, because the devices communicate autonomous, partly or completely without any human interaction involved. In summary, the main purpose of M2M is to provide a simple way to establish a connection between a system, a remote device, and an individual person for data of devices. The connection between two devices may be a wired connection, a wireless connection or a combination of wired and wireless connection. Moreover, an M2M technology integrates data collection, remote monitoring, communication, and information technology, in order to enable more and more devices to have communication and networking capabilities, so that everything can be realized on a network.
M2M communications may take advantage of deployed wireless networks based on Third Generation Partnership Project (3GPP) technologies such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Long Term Evolution Advanced (LTE-Advanced), and/or other technologies such as WiMAX (Worldwide Interoperability for Microwave Access) or those developed by the Institute for Institute of Electrical and Electronics Engineers (IEEE) and 3GPP2.
Within ETSI (European Telecommunication Standards Institute) a standard is being defined for machine to machine communication between devices. The standard focuses mainly on enabling offline communication between the devices. Basically this means that two devices can exchange information without being online at the same time. This kind of communication uses a NSCL (Network Service Capabilities Layer) or GSCL (Gateway Service Capabilities Layer). The NSCL or GSCL can be regarded as a data storage provider or system which performs a mediator function between source devices that generate data for destination devices. To illustrate a very basic use of this mediator function of the data storage provider or system, a simple example shall be described here. An application on a source device that is not always connected wants to send some data to another application on a destination device in the network by means of the data storage provider or system. The data storage provider or system functions much like a database, with resources being identified by a Uniform Resource Locator (URL). The source device would write data to a resource at the data storage provider or system and the destination device would read that resource. If configured accordingly, the destination device could also be notified by the data storage provider upon the writing of the resource by the source device, in order to facilitate synchronization between the source device and the destination device.
The ETSI M2M standard TS 102 690 V1.1.1 (2011-10) defines how resources can be defined and accessed. It details how a source device writes data identified by a URL and a destination device reads the data. The concept relies on both devices using the same URL which uniquely identifies a resource at the data storage provider.
The standard assumes that both devices know what URL to use. In practice, this means that the URL must either be hardcoded into the devices, or be configured manually, by the manufacturer or the user. However, in many cases hardcoding of manufacturer configuration is not possible, because it is not known beforehand which devices must communicate.
At least two problems have been identified with configuration:
Many M2M devices have limited or no input and output possibilities, making manual configuration tedious and error-prone.
Configuring a device is a rather technical endeavour that is deemed complex for the average user.
As an example, consider a scenario where a house with one or more occupants has a boiler that can turn itself off if it detects that no one of the occupants is at home. This detection is based on an app in each of the occupants' mobile phone that knows (=has learned, or is instructed) which mobile network cells or cell-sectors are in the vicinity of the house. In other words, the app in the mobile phone knows whether an occupant is in the vicinity of the house. The app stores this information in a resource assigned to the app of an occupant at a data storage provider. The boiler could use this information from the apps on the mobile phones of the one or more occupants stored at the data storage provider, to decide whether any of the occupants is at home and turn itself on or off in response to the decision.
The problem of the example above is how to connect the mobile phone apps (source devices) to a particular boiler (destination device). An obstacle lies in the boiler, which typically has no display and none or only a few buttons. Configuring a URL in such a device for each occupant it needs to track is a tedious task that is regarded complex for most users. Inputting a URL in the mobile phone app is easier, but still error-prone and complicated for average users.
Another disadvantage of current M2M home automation systems is that the supplier of the system is also the provider of the data storage device providing the resource. The supplier may have access to the private data of the users and could extract valuable data from said private data. With the boiler example, the supplier could know when the users are at home. This can be an undesirable consequence for some users. However, when the data storage provider is unknown before the boiler is made operational for a user, the URL cannot be set when the boiler is manufactured. Consequently, a user has to configure the URL, giving the problems described before.